At times of natural disaster or for other reasons, a storage system and/or network can go offline and/or otherwise become unavailable, which can be referred to as a disaster. If the storage system/network does not include copies of the data stored on the storage system/network, data can be lost, which can be costly in terms of data recovery and/or lost operational time. To ensure that data is not lost during a disaster, many conventional storage systems and/or storage networks utilize a disaster recovery site to store copies of the data.
Different mechanisms exist for making copies of data including application or database level replication, file-system level replication or block storage level replication. Block storage level replication has the advantage that it can be applied as a single generic solution at the storage level so can reduce implementation effort and complexity when compared to a solution involving heterogeneous applications with multiple different application level mechanisms or perhaps with no application level mechanism available.
Conventional block level replication solutions however have the disadvantage that the data is made available at the disaster recovery site in the identical format in which it was stored in the primary site. In order to make use of the data to resume operations after a disaster, the configuration of resources and software at the disaster recovery site must closely correspond to the configuration at the primary site.
While disaster recovery sites assist in data recovery when the storage system/network experiences as disaster, conventional disaster recovery sites and/or the resources maintained thereon are often owned/controlled by a third party. Constrained by the need to maintain disaster recovery configurations closely corresponding to the client's primary resources, these third party owners generally allocate the resources on the disaster recovery site to their clients even when a client is not currently using the resources for disaster recovery operations. As such, conventional disaster recovery sites can be costly for the client because a client is usually required to pay for a service that is not actually being utilized.
Cloud service providers offer infrastructure as a service that may be allocated on-demand, potentially as needed after a disaster and so present an opportunity for reducing cost. Cloud infrastructure may not necessarily be built from the same technology as a client's primary systems though, so it may be difficult to provision a configuration sufficiently similar to the client's primary resources for recovery from a conventional block level replica of the data to be possible.
As a specific example, a client's primary infrastructure may be implemented as a collection of virtual machines provisioned from a private cloud solution based on one hypervisor technology, whereas a cloud service provider may provide infrastructure as a service implemented using a different hypervisor technology with an incompatible format for the virtual machine disk images. In this case, conventional block level replication to the cloud may be insufficient for disaster recovery since the disk images available in the cloud after the disaster would be incompatible with the infrastructure offered as a service by the cloud service provider.
A further issue of significance when considering the use of cloud service providers for disaster recovery is the availability and cost of network bandwidth between the primary site and the cloud service provider's site. Bandwidth may be limited and cloud service providers may charge fees based on the amount of data transferred so there could be considerable cost and time savings from performing incremental data transfers rather than full copies wherever possible.